It is common for multiple threads of a multi-threaded process to share common memory locations during concurrent execution. Consequently, two different threads of a multi-threaded process may read and update the same memory location accessible by the program. However, one thread should not modify a value of the shared memory location while the other thread is in the middle of a sequence of operations that depend on the value.
Software Transactional Memory (STM) is a concurrent programming mechanism in which memory operations are grouped into transactions. A transaction is a sequence of steps executed by a single thread. Transactions are atomic, i.e., each transaction either commits (it takes effect) or aborts (its effects are discarded). Transactions are linearizable or serializable, and appear to take effect in a one-at-a-time order. Transactions are intended to facilitate fine-grained synchronization such that there is no need to track locks that protect objects, and no need for elaborate deadlock-avoidance protocols.
Typical STM implementations allow threads to execute non-conflicting transactions in parallel, enabling data structures that scale with performance similar to that of complicated fine-grained locking, with the programming simplicity of coarse-grained locking. However, such implementations of transactional memory have typically provided unexpected semantics, required the re-compilation of non-transacted code, introduced high overheads, or assumed new hardware.